minifandomcom_de-20200215-history
Fantom-DE/Quellprogramme
Wie scheibt man ein Fantom-Programm? Diese Seite besteht in wesentlichen Teilen aus einer Übersetzung von http://fantom.org/doc/docLang/CompilationUnits.html. Pod-Struktur Zu einem Pod gehörende Dateien sind im Dateisystem in einem oder mehreren Verzeichnissen organisiert. Konventionsgemät sieht der Verzeichnisbaum etwa folgendermaßen aus: * podname/ ** fan/ - .fan Fantom-Quelldateien ** java/ - .java Java-Peer-Programme ** js/ - .js JavaScript-Peer-Programme ** dotnet/ - .cs C#-Peer-Programme ** res/ - mit dem Pod gebündelte Ressourcen ** locale/ - Lokalisierungsdateien ** test/ - .fan Unit-Tests ** build.fan - Build-Script für das Pod ** pod.fandoc - Dokumentation auf Pod-Ebene Jedes dieser Verzeichnisse kann beliebige Unterverzeichnisse enthalten; dies ist jedoch nicht notwendig der Fall. Fantom-Quellprogramme werden in reinen Textdateien mit der Endung .fan gespeichert. Jede von ihnen kann eine oder mehrere Klassen- oder Mixin-Definitionen enthalten. Anders als bei Jave gibt es keine Beschränkung derart, dass jeder Typ seine eigene Quelldatei haben muss. Trotzdem ist es in der Regel sinnvoll, jede Klasse in eine Quelldatei mit entsprechendem Namen zu schreiben. Wenn man allerdings viele kleine Klassen hat, die eng miteinander verknüpft sind, kann es besser sein, sie in einer Quelldatei zusammenzufassen. Zeichenkodierung Es gibt nur eine einfache Regel, des es zu folgen gilt: Alle Fantom-Quelldateien müssen UTF-8-Codiert sein. Noch besser ist es, wenn man sicher sein will, dass die Quellprogramme in jedem beliebigen Editor bearbeitbar sind, nur die einfachen 7-Bit-ASCII-Zeichen zu verwenden (die eine Untermenge von UTF-8 darstellen). Umlaute und Sonderzeichen kann man notfalls duch Unicode-Escape-Sequenzen wie \u1234 darstellen. Bei deutschsprachigen Anwendungen sollte man ohnehin alle Klartext-Passagen konsequent lokalisieren. Die nötigen Mittel dazu sind im Fantom-Paket bereits enthalten (siehe Fantom-Dokumentation). Anatomie einer Quelldatei Die Quelldateien für Fantom-Programme sind sehr einfach aufgebaut. Sie bestehen aus: # Null oder mehr using-Anweisungen # Eine oder mehr Typdefinitionen Die using-Anweisungen importieren Typen aus externen Pods in den eigenen Namensraum. Die Typdefinitionen enthalten die Klassen und Mixins, die in dieser Quelldatei definiert werden sollen. Pods importieren Mit using importieren Sie Typen aus anderen Pods in den eigenen Namensraum. Dies hat zur Folge, dass Sie sie im Programm mit einfachen Typnamen ohne Angabe der qualifizierten Signatur verwenden können. In der einfachsten Form importieren Sier mit using //alle// Typen eines Pod: using inet Diese Anweisung ermöglicht Ihnen, alle im Pod inet definierten Typen über ihren einfachen Namen anzusprechen. Beispielsweise wird der einfache Typname TcpSocket nun zu inet::TcpSocket aufgelöste. Es ist auch möglich, einzelne Typen in den Namensraum zu importieren. Wenn Sie beispielsweise in Ihrem Programm nur inet::TcpSocket benötigen, können Sie diesen Typ einzeln angeben: using inet::TcpSocket In großen Projekten lässt es sich kaum vermeiden, dass dieselben Typnamen in verschiedenen Pods vorkommen (und dies zu ermöglichen, ist ja auch der Sinn der Namensräume). Wenn wir nun solche gleichnamigen Typen in unserem Programm benötigen, müssen wir jeweils den qualifizierten Namen verwenden. Allerdings gibt es auch die Möglichkeit, die using-Anweisung um eine Option as zu erweitern, die einen Typ unter einem anderen Namen verfügbar macht. Angenommen, wir hätten einen Namenskonflikt zwischen den Typen red::Foo und blue::Foo, dann könten wir mit der folgenden Syntax den Typ blue::Foo unter dem Namen BlueFoo importieren: using blue::Foo as BlueFoo The 'using as' statement is for naming collisions - don't use it for bone-headed things like importing 'sys::Str' as 'S' (we've tried to keep key type names short to being with). The 'sys' pod is automatically imported into every compilation unit - in fact it is a compiler error if you try to import 'sys' explicitly. Kommentare Fantom kennt drei Formen von Kommentaren. Die **-Kommentare funktionieren im Prinzip wie //, indem sie den Rest der Zeile zum Kommentar erklären. Andererseits ähneln sie den Dokumentationskommentaren im Stil von Javadoc (/** */) oder C# (///). Indem man einer oder mehreren Zeilen zwei Sternchen voranstellt, kann man eine Typ oder einen Slot dokumentieren: ** Diese Klasse ist echt cool class Cool { ** Tu's einfach Void justDoIt() {} } Die Dokumentationskommenare werden in einfachem Text geschrieben, wobei einige Strukturierungregeln anzuwenden sind (siehe Dokumentation). Mit Fandoc können Sie Ihren Code in einer Weise dokumentieren, die in den Quelldateien als bloßer Text gut lesbar sind, aber in andere Formate wie etwa hübsch formatiertes HTML übersetzbar sind. Kategorie:Fantom